ImmutaデフォルトのSensitive Data Discoveryでどのようなデータが自動タグ付けされるか確かめてみた

さがらです。

Immutaでは、Data Sourceを追加した際にSensitive Data Discoveryで機密データを検知して自動でタグ付けを行ってくれる仕組みが備わっています。

このSensitive Discoveryについてはユーザーが特に設定を行わずともデフォルトで備わっており、ImmutaにBulit-Inされている検知を行うロジック(Built-In Identifiers)と付与されるタグ(Built-In Discovered Tags)については下記のドキュメントにまとまっております。

そんなSensitive Data Discoveryですが、実際にデフォルトのBuilt-in Identifiersではどんなデータに対してタグ付けされるのか、日本語のカラム・レコードを含む場合にどうなるのか、を確かめてみたので本記事でまとめてみます。

注意事項

検証を行った2023年8月18日時点の情報となりますのでご注意ください。

また、ユーザーが独自にSensitive Data Disvoveryの定義を行うカスタム機能もあるので、それで対応出来る場面もあると考えております。

ECサイトのユーザーデータ

ChatGPTにお願いして、ECサイトのユーザーデータを以下の４種類で作ってもらいました。

• パターン１：カラム名「英語」レコードの値「英語」
• パターン２：カラム名「英語」レコードの値「日本語」
• パターン３：カラム名「日本語」レコードの値「英語」
• パターン４：カラム名「日本語」レコードの値「日本語」

このデータについて、どのようにタグ付けがされたかを確認してみます。

パターン１：カラム名「英語」レコードの値「英語」

対象のデータの中身については、下図をご覧ください。

このデータに対しては、下図のようにタグ付けがされていました。

POSTAL_CODEが検知されていないのは違和感があったのですが、ImmutaのBuilt-In Identifiersのドキュメントを見るとPOSTAL_CODEについては日本の郵便番号の形式には対応していなそうなので、それが検知されなかった理由だと考えられます。

Detects strings consistent with a valid US zip code with an optional +4. Only valid 5 digit zip codes are detected. Tags include Discovered.Entity.Postal Code.

また、CREATED_ATとUPDATED_ATはタグ付けされているのにDELTED_ATがタグ付けされていない理由としては、DELETED_ATはすべてのレコードで値がNULLだったことが考えられそうです。

パターン２：カラム名「英語」レコードの値「日本語」

対象のデータの中身については、下図をご覧ください。

このデータに対しては、下図のようにタグ付けがされていました。

パターン１との違いとして、レコードの値が日本語になったNAMEとADDRESSについて、NAMEはタグ付けされましたがADDRESSはタグ付けされませんでした。

また、PHONEもなぜかパターン２ではタグ付けされなかったのですが、パターン２では実際のデータが変わり、03-1234-5678などの2桁-4桁-4桁の電話番号が２レコードあったことが原因として考えられそうです。

パターン３：カラム名「日本語」レコードの値「英語」

対象のデータの中身については、下図をご覧ください。※一番左にID列もありますが、1~10が並んでいるだけなので割愛しています。

このデータに対しては、下図のようにタグ付けがされていました。

カラム名が日本語となっても、問題なく検知されていましたので、基本的にデータの中身を見てタグ付けの判断をしていると言えそうです。

一方で住所について、パターン２では「日本の住所の日本語表記」、パターン３では「日本の住所の英語表記」となったのですが、パターン３の場合は住所にタグ付けがされていました。

パターン４：カラム名「日本語」レコードの値「日本語」

対象のデータの中身については、下図をご覧ください。

このデータに対しては、下図のようにタグ付けがされていました。

パターン３のところでも述べましたが、やはり住所は英語表記じゃないと自動でタグ付けをしてくれなそうですね。

企業の従業員情報に関する英語データ

もう一つ、企業の従業員情報に関する英語のデータについても試してみました。

対象のデータの中身については、下図をご覧ください。

このデータに対しては、下図のようにタグ付けがされていました。

DEPARTMENT、POSITION、MANAGERといった会社特有の属性情報については自動でタグ付けがされませんでした。

また、SALARYやBONUSなども機密性の高い情報ですが、タグ付けはされませんでした。これはImmutaのBuilt-In Identifiersにも該当するIdentifierがないため仕方なさそうですね。ユーザー側で手動タグ付けか、ユーザーのカスタムのSensitive Data Discoveryの実装が必要そうです。

まとめ

この検証を通して、ImmutaのBuilt-In Identifiersを用いたSensitive Data Discoveryについては以下のことがわかりました。

• カラム名では判断せず、レコードの値を見て、Built-In Identifiersでタグ付けするかどうかを判断している
  • レコードの値を見ているため、NULLしか値がないと判断できないためタグ付けされない
• POSTAL_CODEについてはアメリカの５桁の形式のみ対応しており、日本の郵便番号の形式ではBuilt-In Identifiersはタグ付けしてくれない
• 住所に関するカラムのレコードの値は英語表記でないと、Built-In Identifiersではタグ付けしてくれない
• 今回検証した中ではPHONE列のように、一定の割合Identifierに合致しない値があると、タグ付けはされない

おまけ：自動タグ付けされたタグの無効化・有効化

データによっては自動でタグ付けしてもらいたくないのに勝手にタグ付けサれてしまうケースもあると思います。

そんなときは、対象のタグを開いてDisableを押すとすぐに無効化できます！

一度無効化したタグを再度有効化したい場合は、またタグを開いてEnableを押せばOKです！

最後に

ImmutaデフォルトのBuilt-In Identifiersを用いたSensitive Data Discoveryでどのようなデータが自動タグ付けされるか確かめてみました。

今回検証したように日本固有のデータだと対応しないことも多そうですが、自動付与されたタグのDisableもすぐにできるため、まずは一度Built-In Identifiersを用いたSensitive Data Discoveryを試すのが良いと思います！